This Technical Note discusses how AppleTalk applications should work across internets, groups of interconnected AppleTalk networks. It explains the differences between life on a single AppleTalk network and life on an internet.
Changes since April 1990: Added references to AppleTalk Data Stream Protocol (ADSP) and the PPC (Program-to-Program) Toolbox and to Inside Macintosh Volume VI, and changed the section "Am I Running on an Internet?" to point out that with AppleTalk Remote Access, you can be on network zero and be connected to a remote network.
You can read about internets (AppleTalk networks connect by one or more bridges) in Inside AppleTalk. What do you need to do about them?
Make sure you use the Datagram Delivery Protocol (DDP), or a higher AppleTalk protocol based on DDP, like the AppleTalk Transaction Protocol (ATP), AppleTalk Data Stream Protocol (ADSP), or the PPC Toolbox. Be warned that Link Access Protocol (LAP) packets do not make it across bridges to other AppleTalk networks. Also, don't broadcast; broadcast packets are not forwarded by bridges (broadcasting using protocols above LAP is discouraged, anyway).
As usual, use the Name-Binding Protocol (NBP) to announce your presence on the network, as well as to find other entities on the network. Pay special attention to zone name fields; the asterisk (as in "MyLaser:LaserWriter:*") in a name you look up is now important; it means "my zone only" (see the Zone Information Protocol (ZIP) chapter of Inside AppleTalk and the AppleTalk Manager chapter of Inside Macintosh Volume VI for information on finding out what other zones exist). The zone field should always be an asterisk when registering a name.
When handling the network addresses returned by NBPLookUp (or anyone else), don't be surprised if the network number field is nonzero.
Do not assume that there are no routers on the network if your network number is zero. With AppleTalk Remote Access, you can be on network zero and be connected to a remote network. Network applications should look at the SysABridge low-memory global or use the GetZoneList or the GetBridgeAddress or the GetAppleTalkInfo calls to determine if there is a router on the network.
Due to a "race" condition on an internet, it's possible for an exactly-once ATP packet to slip through twice; to keep this from happening, send a sequence number as part of the data with each ATP packet; whenever you make a request, bump the sequence number, and never honor an old sequence number. If you use ADSP or the PPC Toolbox, the protocol will handle out-of-sequence packets and will always deliver data to the client in order.
Further Reference: